It is my understanding from IEEE 802.3 Section 4.2.3.2.1 'Deference' that "If, at the end of the interFrameSpacing, a frame is waiting to be transmitted, transmission is initiated independent of the value of carrierSense." This is also specified in the Deference process pseudo-code in section 4.2.8 just after the initial defer and IFS has completed: : deferring: = false; {allow new transmissions to proceed} while frameWaiting do nothing {allow waiting transmission if any} However, in both Ethernet MACs on the OpenCores site it appears that a transition will be made directly to Idle state at the completion of the IFS state. If CarrierSense has been re-asserted by then, Idle will always transition to Defer state again, even if there is a frame ready that should have caused the preamble to be immediately transmitted. This non-standard behavior also seems to be assumed in the testbench, since others have mentioned that an error is printed out if transmitting begins more than 1 clock after carrier sense is asserted. Depending on the interframe spacing method used, carrier sense could have been asserted by the PHY at any time during the IFS or during the last third of the IFS (modified scheme) and the MAC could still correctly attempt to transmit the waiting frame according to 802.3. This overly polite behavior can result in a sending station being denied access to the medium indefinitely if there is one or more correctly implemented Tx MACs on the same segment that are sending a continuous stream of data in back-to-back frames. This is because the 802.3-conformant Tx MACs will start sending the preamble for the next frame immediately after the IFS, while the OpenCores versions will first go to Idle then sample CarrierSense. This condition is made worse by the double-clocking required to synchronize CarrierSense with the MII Tx clock, since it introduces an additional one to two clock period delay between the time the carrier is sensed by the PHY and the time the PHY status is sampled by the Tx next state logic. The transition to Idle after IFS should not occur if there is a frame waiting, if my understanding is correct. A direct transition from IFS to Preamble state should be made instead. Please let me know if I've made an error in my understanding of the OpenCores Ethernet MAC or the IEEE 802.3 standard. -- View this message in context: http://www.nabble.com/Apparent-half-duplex-deference-logic-error-tp15324291p15324291.html Sent from the OpenCores - Ethernet MAC mailing list archive at Nabble.com.